Pemrofilan Kinerja Ukuran Trek CSS Grid: Tinjauan Mendalam Analisis Perhitungan Tata Letak

CSS Grid telah merevolusi tata letak web, menawarkan kekuatan dan fleksibilitas yang belum pernah ada sebelumnya untuk membuat desain yang kompleks dan responsif. Dengan fitur seperti unit `fr`, `minmax()`, dan ukuran yang sadar-konten, kita dapat membangun antarmuka yang dulunya hanya impian, seringkali dengan kode yang sangat sedikit. Namun, dengan kekuatan besar datang tanggung jawab besar—dan di dunia kinerja web, tanggung jawab itu terletak pada pemahaman biaya komputasi dari pilihan desain kita.

Meskipun kita sering berfokus pada optimisasi eksekusi JavaScript atau pemuatan gambar, hambatan kinerja yang signifikan dan sering diabaikan adalah fase perhitungan tata letak (layout) browser. Setiap kali browser perlu menentukan ukuran dan posisi elemen di halaman, ia melakukan operasi 'Layout'. CSS yang kompleks, terutama dengan struktur grid yang canggih, dapat membuat proses ini mahal secara komputasi, yang menyebabkan interaksi lamban, rendering tertunda, dan pengalaman pengguna yang buruk. Di sinilah pemrofilan kinerja menjadi bukan hanya alat untuk debugging, tetapi bagian penting dari proses desain dan pengembangan.

Panduan komprehensif ini akan membawa Anda menyelam lebih dalam ke dunia kinerja CSS Grid. Kita akan melampaui sintaksis dan menjelajahi 'mengapa' di balik perbedaan kinerja. Anda akan belajar cara menggunakan alat pengembang browser untuk mengukur, menganalisis, dan mendiagnosis hambatan tata letak yang disebabkan oleh strategi ukuran trek grid Anda. Pada akhirnya, Anda akan diperlengkapi untuk membangun tata letak yang tidak hanya indah dan responsif, tetapi juga secepat kilat.

Memahami Pipeline Rendering Browser

Sebelum kita dapat mengoptimalkan, kita harus terlebih dahulu memahami proses yang ingin kita tingkatkan. Ketika browser me-render halaman web, ia mengikuti urutan langkah yang sering disebut sebagai Jalur Rendering Kritis (Critical Rendering Path). Meskipun terminologi pastinya dapat sedikit berbeda antar browser, tahapan intinya umumnya konsisten:

• Style: Browser mengurai CSS dan menentukan gaya akhir untuk setiap elemen DOM. Ini melibatkan penyelesaian selektor, penanganan cascade, dan penghitungan gaya terkomputasi untuk setiap node.
• Layout (atau Reflow): Ini adalah fokus utama kita. Setelah gaya dihitung, browser menghitung geometri setiap elemen. Browser menentukan di mana tepatnya setiap elemen harus diletakkan di halaman dan berapa banyak ruang yang ditempatinya. Ini menciptakan 'pohon tata letak' atau 'pohon render' yang mencakup informasi geometris seperti lebar, tinggi, dan posisi.
• Paint: Pada tahap ini, browser mengisi piksel. Ia mengambil pohon tata letak dari langkah sebelumnya dan mengubahnya menjadi satu set piksel di layar. Ini melibatkan penggambaran teks, warna, gambar, batas, dan bayangan—pada dasarnya, semua bagian visual dari elemen.
• Composite: Browser menggambar berbagai lapisan yang telah di-paint ke layar dalam urutan yang benar. Elemen yang tumpang tindih atau memiliki properti spesifik seperti `transform` atau `opacity` sering ditangani di lapisannya sendiri untuk mengoptimalkan pembaruan berikutnya.

Mengapa Fase 'Layout' Kritis untuk Kinerja Grid

Fase Layout untuk dokumen block-and-inline sederhana relatif mudah. Browser seringkali dapat memproses elemen dalam satu lintasan, menghitung dimensinya berdasarkan induknya. Namun, CSS Grid memperkenalkan tingkat kompleksitas baru. Kontainer grid adalah sistem berbasis batasan. Ukuran akhir dari trek atau item grid seringkali bergantung pada ukuran trek lain, ruang yang tersedia di kontainer, atau bahkan ukuran intrinsik konten di dalam item saudaranya.

Mesin tata letak browser harus menyelesaikan sistem persamaan yang kompleks ini untuk sampai pada tata letak akhir. Cara Anda mendefinisikan trek grid Anda—pilihan unit dan fungsi ukuran Anda—secara langsung memengaruhi kesulitan dan, oleh karena itu, waktu yang diperlukan untuk menyelesaikan sistem ini. Inilah sebabnya mengapa perubahan yang tampaknya kecil pada `grid-template-columns` dapat memiliki dampak yang tidak proporsional pada kinerja rendering.

Anatomi Ukuran Trek CSS Grid: Perspektif Kinerja

Untuk melakukan pemrofilan secara efektif, Anda perlu memahami karakteristik kinerja dari alat yang Anda miliki. Mari kita bedah mekanisme ukuran trek yang umum dan analisis potensi biaya komputasinya.

1. Ukuran Statis dan Dapat Diprediksi

Ini adalah opsi yang paling sederhana dan paling berkinerja karena memberikan informasi yang jelas dan tidak ambigu kepada mesin tata letak.

• Unit Tetap (`px`, `rem`, `em`): Ketika Anda mendefinisikan trek sebagai `grid-template-columns: 200px 10rem;`, browser tahu ukuran pasti dari trek ini segera. Tidak ada perhitungan kompleks yang diperlukan. Ini secara komputasi sangat murah.
• Unit Persentase (`%`): Persentase diselesaikan relatif terhadap ukuran kontainer grid. Meskipun memerlukan satu langkah ekstra (mendapatkan lebar induk), ini masih merupakan perhitungan yang sangat cepat dan deterministik. Browser dapat menyelesaikan ukuran ini di awal proses tata letak.

Profil Kinerja: Tata letak yang hanya menggunakan ukuran statis dan persentase biasanya sangat cepat. Browser dapat menyelesaikan geometri grid dalam satu lintasan yang efisien.

2. Ukuran Fleksibel

Kategori ini memperkenalkan fleksibilitas, memungkinkan trek untuk beradaptasi dengan ruang yang tersedia. Ini sedikit lebih kompleks daripada ukuran statis tetapi masih sangat dioptimalkan di browser modern.

• Unit Fraksional (`fr`): Unit `fr` mewakili sebagian dari ruang yang tersedia di kontainer grid. Untuk menyelesaikan unit `fr`, browser pertama-tama mengurangi ruang yang diambil oleh semua trek non-fleksibel (seperti `px` atau `auto`) dan kemudian membagi sisa ruang di antara trek `fr` sesuai dengan fraksinya.

Profil Kinerja: Perhitungan untuk unit `fr` adalah proses multi-langkah, tetapi ini adalah operasi matematika yang terdefinisi dengan baik yang tidak bergantung pada konten item grid. Untuk sebagian besar kasus penggunaan umum, ini sangat berkinerja.

3. Ukuran Berbasis Konten (Hotspot Kinerja)

Di sinilah hal-hal menjadi menarik—dan berpotensi lambat. Kata kunci ukuran berbasis konten menginstruksikan browser untuk mengukur trek berdasarkan konten item di dalamnya. Ini menciptakan hubungan yang kuat antara konten dan tata letak, tetapi datang dengan biaya komputasi.

• `min-content`: Mewakili lebar minimum intrinsik dari konten. Untuk teks, ini biasanya lebar kata terpanjang atau string yang tidak dapat dipatahkan. Untuk menghitung ini, mesin tata letak browser harus secara nosional menata letak konten untuk menemukan bagian terlebar itu.
• `max-content`: Mewakili lebar pilihan intrinsik dari konten, yaitu lebar yang akan ditempatinya tanpa pemutusan baris selain yang ditentukan secara eksplisit. Untuk menghitung ini, browser harus secara nosional menata letak seluruh konten pada satu baris tunggal yang tak terbatas panjangnya.
• `auto`: Kata kunci ini bergantung pada konteks. Ketika digunakan untuk mengukur trek grid, umumnya berperilaku seperti `max-content`, kecuali item tersebut direntangkan atau memiliki ukuran yang ditentukan. Kompleksitasnya mirip dengan `max-content` karena browser seringkali harus mengukur konten untuk menentukan ukurannya.

Profil Kinerja: Kata kunci ini adalah yang paling mahal secara komputasi. Mengapa? Karena mereka menciptakan ketergantungan dua arah. Tata letak kontainer bergantung pada ukuran konten item, tetapi tata letak konten item mungkin juga bergantung pada ukuran kontainer. Untuk menyelesaikan ini, browser mungkin perlu melakukan beberapa lintasan tata letak. Ia pertama-tama harus mengukur konten setiap item di trek itu sebelum bahkan dapat mulai menghitung ukuran akhir dari trek itu sendiri. Untuk grid dengan banyak item, ini bisa menjadi hambatan yang signifikan.

4. Ukuran Berbasis Fungsi

Fungsi menyediakan cara untuk menggabungkan model ukuran yang berbeda, menawarkan fleksibilitas dan kontrol.

• `minmax(min, max)`: Fungsi ini mendefinisikan rentang ukuran. Kinerja `minmax()` sepenuhnya bergantung pada unit yang digunakan untuk argumennya. `minmax(200px, 1fr)` sangat berkinerja, karena menggabungkan nilai tetap dengan nilai fleksibel. Namun, `minmax(min-content, 500px)` mewarisi biaya kinerja `min-content` karena browser masih perlu menghitungnya untuk melihat apakah lebih besar dari nilai maks.
• `fit-content(value)`: Ini secara efektif adalah penjepit (clamp). Ini setara dengan `minmax(auto, max-content)`, tetapi dijepit pada `value` yang diberikan. Jadi, `fit-content(300px)` berperilaku seperti `minmax(min-content, max(min-content, 300px))`. Ini juga membawa biaya kinerja dari ukuran berbasis konten.

Peralatan yang Digunakan: Pemrofilan dengan Chrome DevTools

Teori itu berguna, tetapi data itu definitif. Untuk memahami bagaimana tata letak grid Anda berkinerja di dunia nyata, Anda harus mengukurnya. Panel Performance di DevTools Google Chrome adalah alat yang sangat diperlukan untuk ini.

Cara Merekam Profil Kinerja

Ikuti langkah-langkah ini untuk menangkap data yang Anda butuhkan:

1. Buka halaman web Anda di Chrome.
2. Buka DevTools (F12, Ctrl+Shift+I, atau Cmd+Opt+I).
3. Navigasi ke tab Performance.
4. Pastikan kotak centang "Web Vitals" dicentang untuk mendapatkan penanda yang berguna di timeline Anda.
5. Klik tombol Record (lingkaran) atau tekan Ctrl+E.
6. Lakukan tindakan yang ingin Anda profilkan. Ini bisa berupa pemuatan halaman awal, mengubah ukuran jendela browser, atau tindakan yang secara dinamis menambahkan konten ke grid (seperti menerapkan filter). Ini semua adalah tindakan yang memicu perhitungan tata letak.
7. Klik Stop atau tekan Ctrl+E lagi.
8. DevTools akan memproses data dan menyajikan timeline terperinci kepada Anda.

Menganalisis Flame Chart

Flame chart adalah representasi visual utama dari rekaman Anda. Untuk analisis tata letak, Anda akan ingin fokus pada bagian thread "Main".

Cari bilah ungu panjang berlabel "Rendering". Di dalamnya, Anda akan menemukan peristiwa ungu yang lebih gelap berlabel "Layout". Ini adalah momen spesifik ketika browser sedang menghitung geometri halaman.

• Tugas Layout Panjang: Satu blok 'Layout' yang panjang adalah tanda bahaya. Arahkan kursor ke atasnya untuk melihat durasinya. Setiap tugas tata letak yang memakan waktu lebih dari beberapa milidetik (misalnya, > 10-15ms) pada mesin yang kuat patut diselidiki, karena akan jauh lebih lambat pada perangkat yang kurang bertenaga.
• Layout Thrashing: Cari banyak peristiwa 'Layout' kecil yang terjadi secara berurutan, seringkali diselingi dengan JavaScript (peristiwa 'Scripting'). Pola ini, yang dikenal sebagai layout thrashing, terjadi ketika JavaScript berulang kali membaca properti geometris (seperti `offsetHeight`) dan kemudian menulis gaya yang membatalkannya, memaksa browser untuk menghitung ulang tata letak berulang kali dalam satu putaran.

Menggunakan Ringkasan dan Monitor Kinerja

• Tab Summary: Setelah memilih rentang waktu di flame chart, tab Summary di bagian bawah memberi Anda diagram lingkaran yang memecah waktu yang dihabiskan. Berikan perhatian khusus pada persentase yang dikaitkan dengan "Rendering" dan secara spesifik "Layout".
• Performance Monitor: Untuk analisis real-time, buka Performance Monitor (dari menu DevTools: More tools > Performance monitor). Ini menyediakan grafik langsung untuk penggunaan CPU, ukuran heap JS, Node DOM, dan yang terpenting, Layouts/sec. Berinteraksi dengan halaman Anda dan melihat grafik ini melonjak dapat langsung memberi tahu Anda tindakan mana yang memicu perhitungan ulang tata letak yang mahal.

Skenario Pemrofilan Praktis: Dari Teori ke Praktik

Mari kita uji pengetahuan kita dengan beberapa contoh praktis. Kita akan membandingkan implementasi grid yang berbeda dan menganalisis profil kinerja hipotetis mereka.

Skenario 1: Tetap & Fleksibel (`px` dan `fr`) vs. Berbasis Konten (`auto`)

Bayangkan sebuah grid produk dengan 100 item. Mari kita bandingkan dua pendekatan untuk kolom.

Pendekatan A (Berkinerja): Menggunakan `minmax()` dengan minimum tetap dan maksimum fleksibel.

grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));

Pendekatan B (Berpotensi Lambat): Menggunakan `auto` atau `max-content` untuk membiarkan konten menentukan ukuran kolom.

grid-template-columns: repeat(auto-fill, minmax(auto, 300px));

Analisis:

• Dalam Pendekatan A, tugas browser sederhana. Ia tahu lebar minimum setiap item adalah 250px. Ia dapat dengan cepat menghitung berapa banyak item yang muat dalam lebar kontainer dan kemudian mendistribusikan sisa ruang di antara mereka. Ini adalah pendekatan ukuran ekstrinsik yang cepat di mana kontainer yang mengontrol. Tugas Layout dalam profil kinerja akan sangat singkat.
• Dalam Pendekatan B, browser memiliki pekerjaan yang jauh lebih sulit. Kata kunci `auto` (dalam konteks ini, sering diselesaikan menjadi `max-content`) berarti bahwa untuk menentukan lebar satu kolom, browser harus terlebih dahulu secara hipotetis me-render konten dari setiap satu dari 100 kartu produk untuk menemukan lebar `max-content`-nya. Kemudian ia menggunakan pengukuran ini dalam algoritma penyelesaian grid-nya. Pendekatan ukuran intrinsik ini memerlukan pekerjaan pengukuran di muka yang sangat besar sebelum tata letak akhir dapat ditentukan. Tugas Layout dalam profil kinerja akan secara signifikan lebih lama, berpotensi satu tingkat besaran.

Skenario 2: Biaya Grid Bersarang Dalam

Masalah kinerja dengan grid dapat bertambah. Pertimbangkan tata letak di mana grid induk menggunakan ukuran berbasis konten, dan anak-anaknya juga merupakan grid yang kompleks.

Contoh:

Tata letak halaman utama adalah grid dua kolom: `grid-template-columns: max-content 1fr;`. Kolom pertama adalah sidebar yang berisi berbagai widget. Salah satu widget ini adalah kalender, yang juga dibuat dengan CSS Grid.

Analisis:

Mesin tata letak browser menghadapi rantai ketergantungan yang menantang:

1. Untuk menyelesaikan kolom `max-content` halaman utama, ia harus menghitung lebar `max-content` dari sidebar.
2. Untuk menghitung lebar sidebar, ia harus menghitung lebar semua anaknya, termasuk widget kalender.
3. Untuk menghitung lebar widget kalender, ia harus menyelesaikan tata letak grid internalnya sendiri.

Perhitungan untuk induk diblokir sampai tata letak anak sepenuhnya diselesaikan. Keterkaitan yang dalam ini dapat menyebabkan waktu tata letak yang sangat panjang. Jika grid anak juga menggunakan ukuran berbasis konten, masalahnya menjadi lebih buruk. Memprofilkan halaman seperti itu kemungkinan akan mengungkapkan satu tugas 'Layout' yang sangat panjang selama render awal.

Strategi Optimisasi dan Praktik Terbaik

Berdasarkan analisis kami, kami dapat menurunkan beberapa strategi yang dapat ditindaklanjuti untuk membangun tata letak grid berkinerja tinggi.

1. Utamakan Ukuran Ekstrinsik Daripada Ukuran Intrinsik

Ini adalah aturan emas kinerja grid. Sebisa mungkin, biarkan kontainer grid menentukan dimensi treknya menggunakan unit seperti `px`, `rem`, `%`, dan `fr`. Ini memberi mesin tata letak browser serangkaian batasan yang jelas dan dapat diprediksi untuk bekerja, menghasilkan perhitungan yang lebih cepat.

Daripada ini (Intrinsik):

grid-template-columns: repeat(auto-fit, max-content);

Utamakan ini (Ekstrinsik):

grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

2. Batasi Cakupan Ukuran Berbasis Konten

Ada kasus penggunaan yang valid untuk `min-content` dan `max-content`, seperti untuk menu dropdown atau label di sebelah bidang formulir. Ketika Anda harus menggunakannya, cobalah untuk membatasi dampaknya:

• Terapkan pada sedikit trek: Gunakan pada satu kolom atau baris, bukan pada pola berulang dengan ratusan item.
• Batasi induk: Tempatkan grid yang menggunakan ukuran berbasis konten di dalam kontainer yang memiliki `max-width`. Ini memberi mesin tata letak sebuah batasan, yang terkadang dapat membantunya mengoptimalkan perhitungan.
• Gabungkan dengan `minmax()`: Sediakan nilai minimum atau maksimum yang masuk akal di samping kata kunci berbasis konten, seperti `minmax(200px, max-content)`. Ini dapat memberi browser awal yang baik pada perhitungannya.

3. Pahami dan Gunakan `subgrid` dengan Bijak

`subgrid` adalah fitur canggih yang memungkinkan grid bersarang mengadopsi definisi trek dari grid induknya. Ini fantastis untuk penyelarasan.

Implikasi Kinerja: `subgrid` bisa menjadi pedang bermata dua. Di satu sisi, ini meningkatkan keterkaitan antara perhitungan tata letak induk dan anak, yang secara teoretis dapat memperlambat penyelesaian tata letak awal yang kompleks. Di sisi lain, dengan memastikan item selaras sempurna dari awal, ini dapat mencegah pergeseran tata letak dan reflow berikutnya yang mungkin terjadi jika Anda mencoba meniru penyelarasan secara manual dengan metode lain. Saran terbaik adalah melakukan pemrofilan. Jika Anda memiliki tata letak bersarang yang kompleks, ukur kinerjanya dengan dan tanpa `subgrid` untuk melihat mana yang lebih baik untuk kasus penggunaan spesifik Anda.

4. Virtualisasi: Solusi Utama untuk Kumpulan Data Besar

Jika Anda membangun grid dengan ratusan atau ribuan item (misalnya, grid data, galeri foto dengan scroll tak terbatas), tidak ada jumlah penyesuaian CSS yang akan mengatasi masalah mendasar: browser masih harus menghitung tata letak untuk setiap elemen.

Solusinya adalah virtualisasi (atau 'windowing'). Ini adalah teknik berbasis JavaScript di mana Anda hanya me-render segelintir elemen DOM yang saat ini terlihat di viewport. Saat pengguna menggulir, Anda menggunakan kembali node DOM ini dan mengganti kontennya. Ini menjaga jumlah elemen yang harus ditangani browser selama perhitungan tata letak tetap kecil dan konstan, terlepas dari apakah kumpulan data Anda memiliki 100 atau 100.000 item.

Pustaka seperti `react-window` dan `tanstack-virtual` menyediakan implementasi yang kuat dari pola ini. Untuk grid skala besar, ini adalah optimisasi kinerja paling efektif yang bisa Anda buat.

Studi Kasus: Mengoptimalkan Grid Daftar Produk

Mari kita telusuri skenario optimisasi realistis untuk situs web e-commerce global.

Masalahnya: Halaman daftar produk terasa lamban. Ketika jendela browser diubah ukurannya atau filter diterapkan, ada jeda yang nyata sebelum produk-produk mengalir kembali ke posisi barunya. Skor Core Web Vitals untuk Interaction to Next Paint (INP) buruk.

Kode Awal (Kondisi "Sebelum"):

Grid didefinisikan sangat fleksibel, memungkinkan kartu produk menentukan lebar kolom berdasarkan kontennya (misalnya, nama produk yang panjang).

.product-grid {
display: grid;
grid-template-columns: repeat(auto-fill, fit-content(320px));
gap: 1rem;
}

Analisis Kinerja:

1. Kami merekam profil kinerja saat mengubah ukuran jendela browser.
2. Flame chart menunjukkan tugas 'Layout' yang panjang dan berulang setiap kali event resize diaktifkan, memakan waktu lebih dari 80ms pada perangkat rata-rata.
3. Fungsi `fit-content()` mengandalkan perhitungan `min-content` dan `max-content`. Profiler mengonfirmasi bahwa untuk setiap perubahan ukuran, browser dengan panik mengukur ulang konten semua kartu produk yang terlihat untuk menghitung ulang struktur grid. Inilah sumber kelambatan.

Solusi (Kondisi "Setelah"):

Kami beralih dari model ukuran intrinsik berbasis konten ke model ekstrinsik yang ditentukan oleh kontainer. Kami menetapkan ukuran minimum yang tegas untuk kartu dan membiarkannya melentur hingga sebagian kecil dari ruang yang tersedia.

.product-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
gap: 1rem;
}

Di dalam CSS kartu produk, kami menambahkan aturan untuk menangani konten yang berpotensi panjang dengan anggun di dalam kontainer baru yang lebih kaku ini:

.product-title {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}

Hasilnya:

1. Kami merekam profil kinerja baru saat mengubah ukuran.
2. Flame chart sekarang menunjukkan tugas 'Layout' sangat singkat, konsisten di bawah 5ms.
3. Browser tidak perlu lagi mengukur konten. Ia melakukan perhitungan matematis sederhana berdasarkan lebar kontainer dan minimum `280px`.
4. Pengalaman pengguna berubah. Mengubah ukuran menjadi mulus dan instan. Menerapkan filter terasa cepat karena browser dapat menghitung tata letak baru hampir secara instan.

Catatan tentang Peralatan Lintas Browser

Meskipun panduan ini berfokus pada Chrome DevTools, penting untuk diingat bahwa pengguna memiliki preferensi browser yang beragam. Firefox's Developer Tools memiliki panel Performance yang sangat baik (sering disebut 'Profiler') yang menyediakan flame chart dan kemampuan analisis serupa. Safari's Web Inspector juga menyertakan tab 'Timelines' yang kuat untuk memprofilkan kinerja rendering. Selalu uji optimisasi Anda di seluruh browser utama untuk memastikan pengalaman yang konsisten dan berkualitas tinggi untuk seluruh audiens global Anda.

Kesimpulan: Membangun Grid Berkinerja Tinggi Sejak Awal Desain

CSS Grid adalah alat yang sangat kuat, tetapi fitur-fitur paling canggihnya tidak bebas dari biaya komputasi. Sebagai profesional web yang mengembangkan untuk audiens global dengan berbagai macam perangkat dan kondisi jaringan, kita harus sadar akan kinerja sejak awal proses pengembangan.

Poin-poin pentingnya jelas:

• Layout adalah hambatan kinerja: Fase 'Layout' dari rendering bisa mahal, terutama dengan sistem berbasis batasan yang kompleks seperti CSS Grid.
• Strategi ukuran penting: Ukuran ekstrinsik yang ditentukan oleh kontainer (`px`, `fr`, `%`) hampir selalu lebih berkinerja daripada ukuran intrinsik berbasis konten (`min-content`, `max-content`, `auto`).
• Ukur, jangan menebak: Profiler kinerja browser bukan hanya untuk debugging. Gunakan secara proaktif untuk menganalisis pilihan tata letak Anda dan memvalidasi optimisasi Anda.
• Optimalkan untuk kasus umum: Untuk koleksi item yang besar, definisi grid ekstrinsik yang sederhana akan memberikan pengalaman pengguna yang lebih baik daripada yang kompleks dan sadar-konten.

Dengan mengintegrasikan pemrofilan kinerja ke dalam alur kerja rutin Anda, Anda dapat membangun tata letak yang canggih, responsif, dan kuat dengan CSS Grid, dengan keyakinan bahwa mereka tidak hanya menakjubkan secara visual tetapi juga sangat cepat dan dapat diakses oleh pengguna di mana saja.